Integrated circuits are nowadays used in virtually all kinds of electronic apparatuses. In more advanced forms, the integrated circuit contains programmable logic circuitry (i.e. a processing unit), associated volatile and non-volatile memories, and function-specific circuitry (for instance, radio communication circuitry). Such an integrated circuit is sometimes referred to as a digital System On Chip (SOC).
One common kind of electronic apparatuses where integrated circuits such as digital SOCs are used is a mobile terminal for radio communication pursuant to one or more standards for mobile telecommunication such as, for instance, one or more of GSM, UMTS, LTE, D-AMPS, CDMA2000, FOMA or TD-SCDMA. A mobile terminal will be used herein as a non-limiting example of an electronic apparatus comprising an integrated circuit according to the present disclosure.
A mobile terminal often is required to operate in a well-defined fashion, typically due to:
1. standards requirements (such as radio interface requirements)
2. third-party requirements (such as Digital Rights Management (DRM))
3. security requirements (such as preventing malicious software, for instance in the form of a trojan or a virus-infected software) from running or at least accessing protected resources.
An integrated circuit (e.g. SOC) contained in the mobile terminal is of course also subjected to such requirements, where applicable. This means that the integrated circuit needs to authenticate new or modified program code that an external device is trying to upload to the integrated circuit. The integrated circuit also needs to verify that an external device, when seeking access to protected resources on the integrated circuit, actually has the authority to do so.
One situation where the above considerations become an issue is testing of integrated circuits. As with any semiconductor devices, mass-production of integrated circuits will not be perfectly free from errors. Hence, test methods and devices are needed. An industry standard known as Joint Test Action Group (JTAG) is available for this purpose. To facilitate testing, an integrated circuit is often provided with a JTAG compliant interface, such as IEEE 1149.1 or IEEE 1149.7.
Generally, testing of integrated circuits can be divided in two main types, production-line testing and field return testing.
Production-line testing occurs en masse for a large number of integrated circuit at the production plant. An external device is connected to the JTAG interface of the integrated circuit and performs low-level testing activities such as boundary scan testing. In addition, integrated circuits are often designed to have a test operation mode called Functional Test Vectors (FTV). FTV mode allows further examination of an integrated circuit by running certain program code on the integrated circuit under control from the external device, which is often referred to as debug host (or debug tool). Production-line testing is time-critical (delays in production time is expensive); therefore FTV mode testing is normally limited to a short testing period of a few seconds or so.
On the other hand, FTV mode production-line testing does not pose a particular security problem, since it takes place at the production plant. For performance reasons, no authentication of the debug host is used in FTV mode. However, since it might be possible for third parties to perform FTV mode testing on an integrated circuit once released on the field, the integrated circuit is normally designed to disable certain sensitive features when run in FTV mode. Several examples of such sensitive features are given later on in the Detailed Description section and are collectively referred to as protected resources in this disclosure.
Field return testing of faulty samples of the integrated circuit (and/or the electronic apparatus it is part of) often requires manual investigation of reported problems. Such investigation requires debugging and checking all on-chip functions. Since integrated circuits are typically locked down after completion at the production line, an integrated circuit being subjected to field return testing needs to verify that a debug host is authentic, and/or actually has the authority to command debug operations—particularly those which pertain to protected resources on the integrated circuit. Otherwise, a severe security risk appears.
Another situation where the above security considerations become an issue is the enabling of secured debug during development. If a debug operation involves uploading of new or updated program code onto the integrated circuit, the integrated circuit needs to authenticate the uploaded program code, before storing or at least running it.
In order for such authentication, authorization or uploading of program code to be possible, authentication data, authorization data or program code must be transferred onto the integrated circuit from the outside. Such uploading may however be problematic. Even though the integrated circuit typically has standard functional interfaces like UART or USB, those interfaces are often already connected to a host device (such as an application processor) in the electronic apparatus. Host device support to provide the required data upload may not be present.
One approach might be to add extra components, allowing a debug host to break up for instance a UART link between the integrated circuit and the host device. Adding extra components however is difficult because of constraints in space/circuit area as well as costs. Such an approach might also require that the interface (e.g. UART) at some point be switched from the debug host to the on-PCB host, which requires synchronization between the debug host and the host device in the electronic apparatus.
In fact, for certain minimized integrated circuits with small form factors, it may not even be possible to add extra connectors for a UART or USB interface.
A further complication is that some on-chip interfaces may have been permanently disabled for functional reasons. For example, a certain customer of an integrated circuit manufacturer may have chosen to disable boot over UART, in case that would otherwise interfere with the particular use of the corresponding interface pins that the customer has in mind.
As is apparent from the above, there are both needs and room for improvements with respect to these problems.